Security-JAWS 第35回レポート #secjaws #secjaws35 #jawsug
Security-JAWS 第35回のレポートです。
2024.11.18こんにちは、臼田です。
Security JAWS 第35回が開催されましたのでレポート致します。
Security-JAWS【第35回】 勉強会 2024年11月18日(月) - connpass
ちなみに前回から、Connpassを利用しています。今後はConnpass中心となりますので、ぜひSecurity-JAWSのページからメンバー登録いただけると助かります。
動画
後ほど
レポート
Session1: クリティカルなシステムの運用を AWS Incident Detection and Response で強化する アマゾンウェブサービスジャパン 技術支援本部 庄司哲也さん
- 普段は事業開発としてAWSサポートを担当している
- ぬくもりを持って提供している
- 技術者ではないのでお手柔らかに
- AWSサポートの全体像
- 大きく分けるとサポートプラント有償オプションの2つ
- サポートプランはベーシック・開発・ビジネス・エンタープライス On-Ramp・エンタープライズ
- 有償オプションにCountdown Premium・re:post Private・IDR
- ここ最近で色々増えた
- お客様のサポートに求める要件が変わってきた
- 幅広く支援させてもらっている
- サポートプラン
- ベーシックは技術的なサポートは無し
- 開発者から技術的なサポートがある
- ただし平日9-18時対応
- ビジネスだと24365
- 本番ワークロード向けの基本的なプラン
- 日本語を話すエンジニアが最短1時間で初回応答
- お客様のユースケースを踏まえたアーキテクチャガイダンス
- コンテキストに応じた支援ができる
- Trusted Advisorなど便利機能が利用できる
- エンタープライズはミッションクリティカルなワークロード向け
- TAMによる支援がある
- On-Rampだとチーム支援になる
- サポートを使うときのポイント
- 技術的なお問い合わせに関するガイドライン
- 正しい問い合わせ方法を理解するのが大事
- タイトルに緊急度を入れても反映されない
- プルダウンで選びましょう
- 問題が今起きているのかどうかを書く
- リソースを具体的に明記する
- などなど
- タイトルに緊急度を入れても反映されない
- 最近Slackアプリでサポート連携できるようになった
- AWS Support Slack のアプリ - AWS Support
- 普段Slackを使っているならより使いやすい
- AWS Incident Detection and Response(IDR)
- ここでいうインシデントはセキュリティのインシデントではない
- アベイラビリティ(可用性)のインシデントが対象
- もちろんDDoSなどがあればアベイラビリティにも影響があるので対応する
- アベイラビリティと関係ないセキュリティのインシデントはスコープ外
- お客様の声
- エンドカスタマーからの深刻が来て初めて障害に気づいた
- 問題箇所の特定を素早くしたい
- IDRとは
- お客様システムに障害が発生した際に、AWSがプロアクティブに初動対応を行うことで早期復旧を支援するサービス
- AWSのインシデントマネージャーが対応を開始する
- どうやるのか？
- インシデントマネージャーが24365でお客様システムのアラームをモニタリングしている
- インシデントマネージャーがアラームにお客様と同時に気づく
- 一緒に対応していく
- 5分以内で応答する
- ここでいうインシデントはセキュリティのインシデントではない
- Accelerated recovery path
- 従来だと障害が発生したら検知して、お客様自身で確認してAWSへの問い合わせ
- エンタープライズプランで15分以内にAWSが初回応答する
- IDRだと障害発生時すぐにAWSが気づきお客様に連絡
- Web会議にすぐに入って会話できる状態になる
- 調査も並列で行われる
- 従来だと障害が発生したら検知して、お客様自身で確認してAWSへの問い合わせ
- 詳細な仕組み
- お客様側でオブザーバビリティの仕組みがある状態から始まる
- アラームの中から特に重要なものだけ選定して、EventBridgeを経由して通知してもらう
- インシデントマネージャーがアラートを受け取ったらお客様固有のランブックを見ながら対応
- ランブックにはお客様のビジネスやアーキテクチャなどが書かれているのでそれを使って対処を開始する
- どのアラームで誰に連絡するかなども書いてある
- アラームの要件の設定とランブックの作り込みをサービスのオンボーディングをしていく
- IDRをどうやって活用するか
- 日頃からインシデント対応の体制を整える
- たとえばオンボーディングの中では誰に連絡するか、連絡がつかないなら何分後に誰に連絡するかなどを詰める
- アラームの設計も重要
- アラームがたくさんあったりオンプレのままで見直しできていない、とかの課題もある
- アラームについてはIDRのチームがベストプラクティスを公開している
- Lambda - Incident Detection and Response Alarming Best Practices | AWS re:Post
- 日頃からインシデント対応の体制を整える
感想
セキュリティインシデントはスコープ外ですが、可用性も大事な守っていくポイントですね。
よりミッションクリティカルな環境では参考になりますし、そうでなくても考え方は参考になりますのでサービスを正常に運用するための参考にしましょう！
Session2: コンテキスト重視のCNAPP Tenable Network Security 株式会社 Masa Itoさん
- アジェンダ
- CNAPPまわりの話
- 話さないこと
- 営業目的の話
- ゴール
- CNAPPとはどんなものかをザクッと理解いただく
- CNAPPまわりで話題になったこと
- Google親会社のアルファベットがWizを買収するニュースになった
- 結果拒絶した
- CNAAPPという領域が注目を集めている
- CNAPPとかCTEM
- いろんな用語がある
- Continuous Threat Exposure Management
- 継続的にシステムやデータのセキュリティリスクを評価し管理するためのアプローチ
- CNAPP
- クラウドネイティブアプリケーションを保護するための領域
- 今回はCNAPP部分を話す
- CNAPPは一括りにはできない
- クラウドで動いているアプリケーションもいろいろある
- いろんな言語のソースコードもあります
- そこを保護するのはSAST/DAST/IAST/RASPなど
- OSSもたくさん使っているのでチェックする
- SCA/SBOM
- IaCに対してもスキャンする
- VM/Containerにはワークロード保護やimageスキャン
- インフラにCSPMなど
- CNAPPはいろんなレイヤーを見る
- 上の方は最近はASPMと言ったりもする
- シフトレフト/DevSecOps系
- 上の方は開発者側で下の方はオペレーションになったりする
- Tenableはインフラ寄りの方を見る
- コンテキストが重要
- CWPで脆弱性を検出して、実際にどれくらい公開されているか・設定ミスはあるかという状態と掛け合わせてリスクを判断する
- CIEMで高い権限の管理もする
- 実際のCNAPP
- いろんなクラウドが見れる
- 資産の一覧が見れる
- いろんな検出が見れる
- 組み合わさると危ないものが抜粋して出てくる
- ネットワークも可視化して表示してくれる
- コンテキストを補完して説明してくれる
- CNAPPは色んなところを見る
感想
CNAPPと一言で言ってもいろんな領域があるので、各領域についてどうするか検討していかないとですね。
Session3: クラウドにおけるマルウェアやコンテンツ改ざんへの対策について 佐田 淳史さん
- 事業会社のSecurity Engineerをやっている
- IPA10大脅威
- 1位はランサムウェア
- クラウドならではの対策の発信は需要が高いのではないか？
- Threat Hunting
- 既存のセキュリティ対策を回避する脅威を調査してサイバーレジリエンスを向上する
- FISCと金融庁のサイバーレジリエンス
- 事前にリスクをすべて洗い出して対策することは難しい
- リスクゼロを追求することは必ずしも合理的ではないというスタンス
- リスク属性に応じて対策していくと良い
- ランサムウェアの流れ
- BlackHatUSAから引用
- マルウェアの配布と感染
- C2
- 発見とラテラルムーブメント
- データの抽出と改ざん
- データの暗号化
- 恐喝
- 解決？
- AWSからe-bookが提供されている
- 具体的な方法は解説されていない
- 具体的にどう取り組めばいいか
- account isolation
- ADがない環境であれば侵害された影響はアカウント内に閉じる
- アカウントを分けることで分離ができる
- WORM storage
- Write Once Read Manyの略
- 書き込んだデータを消去・変更できない追記型の記憶方式
- バックアップ含めて暗号化されたりするリスクを防止できる
- AWSだとS3 Object LockとVault Lock
- S3 Object Lock
- バケットレベルで有効化できる
- AWS Backup Vault Lock
- 保持ポリシーで各バックアップを削除できなくなる
- ECSのRead Onlyマウント
- ファイルシステムをRead Onlyでマウントすると改ざんリスクを低減できる
- SSM Agentを起動できるようにすることで副作用を防止する
- account isolation
- まとめ
- 保護のための不十分なバックアップは気をつけよう
- 他にもいろんな対策があるのでそちらもやっていこう
感想
ランサムウェアの対策にバックアップは必須ですね。単純にセキュリティのためだけではなくそもそもBCDRの要件からもバックアップの要件の設計が必要なので、そこから検討していきましょう。
Session4: VPC Traffic Mirroring と OSS を利用したネットワークフォレンジック基盤の構築・運用 株式会社リクルート 須藤 悠さん
- 好きなAWSのサービスはAWS Organizations
- リクルートは21年に統合された
- マッチング&ソリューション事業をしている
- いろんなサービスを展開している
- ネットワークフォレンジック基盤の構成
- 共通ネットワークフォレンジックの基盤を作っている
- Arkimeを使っている
- SOCに対してパケット分析環境を提供している
- ここでTraffic Monitoringを活用している
- M6g.largeを6台でキャプチャ
- R6g.largeのOpenSearch
- EFSに書き込み
- ネットワークフォレンジック基盤の歴史
- 2019年Traffic Monitoringリリースとともに検討開始
- 2020年Arkimeを使って提供開始
- 2021年にはOpenSearch Serviceがでて載せ替え
- 2024年 52のAWSアカウントに提供
- なぜVPC Traffic Mirroringなのか
- プロダクトのトラフィック上に障害点が増えないのがメリットで採用した
- 従来のようにアプライアンスを入れたりGWLBを経由したりすると障害点が増える
- プロダクトの障害原因にならないようにする
- デメリットとして100%ミラーされることを保証されていない
- 考慮点
- ミラーリングの問題がないかメトリクスを収集している
- CWメトリクスから収集してカスタムメトリクスとして集積・モニタリングしている
- インスタンスの変更がある
- ALBのTargetGroup配下のすべてのインスタンスにMirror Sessionを貼る機能を提供している
- 制約
- ミラー元として利用できるインスタンスタイプが限られる
- Fargate非対応
- 新しいインスタンスは軒並み非対応で最近不便
- ミラー元インスタンス内でMTU設定が必要
- ヘッダが54bytes追加される
- MTUを8947 bytesに設定する
- ミラー元として利用できるインスタンスタイプが限られる
- Arkimeの機能上の制約
- S3 Writerは大量のトラフィックを裁けないためストレージにEFSを使っている
- OpenSearchは利用できるがOpenSearch Serverlessは利用できない
- まとめ
- メリット・デメリットをよく理解したうえでVPC Traffic Mirroringを利用している
- 利用するシステム構成に制約がある
- Arkimeの実装による制約もある
感想
重厚なフォレンジック環境ですごいですなー
Fargate対応などは欲しい機能ですね！
![[参加レポート] 第26回クラウド女子会 AWS BuilderCardsをプレイしよう #cloudgirl #jawsug](https://devio2024-media.developers.io/image/upload/v1730540918/user-gen-eyecatch/vf89er8xbjntpesixv4u.png)
